上篇提到有關server端常用的部署策略們與其優缺點

這篇來聊我自己對Windows application的監控與部署經驗

以及為什麼軟體維運的測試右移需要做到這種程度XD?

雖然產品間差異大不一定通用，但我覺得蠻有趣，所以就來分享一下。

怎麼知道產品在客戶端出事了？

以我的例子來講，產品是一個Endpoint security solution

Windows application (Agent) 是一個client-server架構

把Agent裝在客戶的PC上，就可以做雲端掃毒、防勒索病毒、設定policy等功能

其中最難處理的問題是，當Windows Agent在客戶環境「死掉」或是「失聯」

而很多時候是因為版本升級的過程中有意外發生，幾乎很難讓它自然好轉

所以一開始收集資料是為了除錯，找到Crash或藍屏(BSoD)等嚴重系統問題

設計Agent有心跳聲資料，回傳給後端資料庫最後上線狀態(Last Connected Time)

讓整個除錯時間更明確，讓我們知道它什麼時候失聯的，在找Log的時候會比較方便

而為了想要找到在客戶端升級失敗的原因，必須有辦法可以收集當下出問題的Log

藉由分析遙測資料發現確實有一小批安裝在客戶端的Agent

可能因為重開機或是還沒有死透，依然可以發現它們活得很好（？）

雖然它沒有辦法升級到最新的版本，但如果有log就可以修一些內部未知的問題

於是大神前輩利用Windows schedule task一步步實現Remote collect log功能

相較於複雜的程式邏輯，Windows排程很單純地去檢查後端有沒有on-demand的任務要做

比如說去找有沒有特定的debug log或crash dump生成在某個位置下，

如果有的話，那就把它打包起來傳到AWS S3上面，可以讓維運團隊去抽絲剝繭找原因。

這同時也是SaaS架構的優勢，網路環境相對開放，比起封閉環境來說招數還是很多。

這個時候團隊從利用遙測資料發現問題，到想辦法把客戶端的黑箱變成白箱來去除錯。

怎麼遠端解決客戶端問題

上面發明了Remote collect log來做除錯，那找到問題後該怎麼解決問題呢？

主要我覺得可以分為兩種解法：

1. Solution: 找到產品缺陷，出正式Hotfix做版本升級。
2. Workaround: 屬於個別環境現象，各自處理。

第一種則是發現產品本身的bug，排進下一次的Hotfix版本更新來做產品品質的改進。

第二種可能是客戶環境造成的效能或相容性問題，可以通過發現原因來做個案處理

一般來說，很大咖的客戶會要求你先把他一台出問題的機器用Workaround處理好後

在用Solution official release的方式，正式撒給所有其他的客戶端。

而後者對於維運團隊來說，可能又會有很多不同的奇技淫巧來去處理個案

舉凡設計Retry機制、Restart App等，Windows可以默默(偷)做的事真的很多，

這邊就不多做贅述，但有時候使用很簡單的邏輯比起設計超複雜的架構來得有用。

提早發現問題的意義就在於可以防範未然，把大事化小、小事化無。

至此，測試右移的實踐已經在生產環境(Production)發揮得淋漓盡致。

測試右移最吸引我的點就在於我們是直接看到問題，然後想各種辦法去解決問題

以及把實戰學到的經驗套用到測試左移之中，不斷優化思考上的策略。

測試左右移應該都講得差不多了，剩下幾篇就來補一些QA相關資訊。

下篇來補充說明版本升級跟發布(Hotfix release)